Case Study 3

Kiko Fernandez Reyes

Sept 27, 2017

Tracking Wine

Overview

  • Groups of 4 - 5 people
  • 1st hour:
  • 2nd hour
    • Requirements
    • Design activity diagram
  • break
  • 2nd hour:
    • Discussion: another group’s design
    • Design class diagram
    • Discussion: another group’s design

Case Study

Startup Idea

  • Swiss love their wine and cheese
  • Let’s create a simple wine tracker system

La Cave Vivante

Simple idea

  • Bottles have a RFID tag
  • RFID reader (emits and read signal)
  • Raspberry Pi
  • Server (online shop)
  • Mobile app

Simple idea

Simple idea

Requirements I

The Raspberry Pi needs to handle:

  • Bottles in
  • Bottles out
  • Communication with server
  • Addition: Cellar identity (update cellar)
  • Addition: Employees have Tag (identity)
  • Important: Unreachable server?

Requirements II

The online shop needs to handle:

  • credit cards,
  • invoices,
  • manage cellar (incr / dec)
  • auto-order ( #wine < 5 => send more)
  • auto-order alerts (emails, sms, etc)
  • drink with responsibility alarm
  • …

Activity Diagram

  • Models control flow (of sequence) of activities
  • Represents business ideas rather than implementation
  • High level understanding

Activity Diagram (work in groups)

Break

Class Diagram

  • Static view of the application
  • Represent software entities (classes, interfaces, etc)
  • High level overview of the implementation [1]

[1]: Does the level of detail of {UML} diagrams affect the maintainability of source code?: a family of experiments

Class Diagram (work in groups)

Hint: Domain objects

  • Wine
  • Tag ID
  • Location
  • Region
  • Cellar
  • Type of grape
  • User
  • RFID reader (polls data)
  • Server (where to send data)
  • Online shop (credit card, emails, sms, alerts)

Conclusion

  • Activity diagram
    • convey general idea (business)
    • sequence of steps
  • Static diagram
    • models software entities
    • static view